Week Overview
Mon – Fri · 10 hours total
Build a VPN in three stages — PSK, certificates, then WireGuard
Week 5 is the most conceptually dense week of the course. Students build a complete site-to-site VPN between S1 and S3, starting with the simplest possible authentication method (a pre-shared key), then migrating to certificate-based authentication using a PKI that they build themselves, and finally building a WireGuard tunnel as a modern contrast. By Friday, they have experienced the full spectrum from IPSec's complexity to WireGuard's simplicity — and can explain why each exists.
The week builds directly on Week 4. The SSL certificate generated for Nginx used a self-signed cert with no CA chain behind it. The VPN certificate lab formalises that process: students create a root CA, issue server certificates from it, distribute the CA trust, and configure each endpoint to authenticate using its certificate. The PKI concepts are the same; the application is different.
The network topology expands this week. S3 gains a second NIC connected to a new internal subnet (LAN2 equivalent), acts as a NAT gateway for that subnet, and the VPN creates an encrypted tunnel between S1's LAN1 and S3's LAN subnet. S2 and S3's internal clients can then reach each other through the tunnel — the goal that motivates the entire week.
Week at a glance
Monday
VPN Concepts & Environment
IPSec architecture, IKE phases, ESP/AH, tunnel vs transport, topology setup — S3 as second gateway (Lab 5A)
Tuesday
StrongSwan PSK Tunnel
Install strongswan, ipsec.secrets PSK, ipsec.conf connection block, modified NAT rule, ipsec status verification (Lab 5B)
Wednesday
PKI & Certificate Authority
strongswan-pki, CA key and cert generation, issue server certs for S1 and S3, distribute trust (Lab 5C)
Thursday
Certificate-Based IPSec & WireGuard
Migrate PSK to RSA cert auth, verify SA, then WireGuard — key pairs, [Interface]/[Peer] config, routing, comparison (Lab 5D)
Friday
Mini-Assessment 5
Written: VPN concepts, IPSec config syntax, PKI, WireGuard. Practical: bring up a WireGuard tunnel from a spec.
Learning Outcomes
By end of Week 5, students can…
Explain IPSec architectureDescribe IKE Phase 1 and Phase 2, the difference between ESP and AH, and when tunnel mode vs transport mode is used
Configure a StrongSwan PSK tunnelWrite ipsec.secrets and ipsec.conf on both endpoints, apply the correct NAT exclusion rule, and verify the SA with ipsec status
Verify VPN traffic with tcpdumpCapture encrypted ESP packets on the external interface and confirm traffic is flowing through the tunnel
Build a PKI with strongswan-pkiGenerate a CA private key, self-sign a root CA certificate, issue server certificates for both VPN endpoints, and inspect certificates with ipsec pki --print
Migrate a PSK tunnel to certificate authUpdate ipsec.secrets to RSA, add leftcert/leftid/rightid to ipsec.conf, distribute necessary files, and verify the SA re-establishes
Configure a WireGuard tunnelGenerate key pairs, write [Interface] and [Peer] sections on both endpoints, add routing, and verify connectivity
Compare IPSec and WireGuardArticulate the differences in complexity, configuration, code size, performance, and appropriate use cases
Monday
Lecture + Lab 5A · 2 hrs
VPN fundamentals, IPSec architecture, and expanding the lab topology for S3
0:00–0:30
Lecture
0:30–1:50
Lab 5A
1:50–2:00
Debrief
- Lecture (30 min): Why VPNs — the problem of connecting two isolated networks across an untrusted medium. Tunnel mode vs transport mode. IPSec protocol suite: IKE (key exchange), ESP (encryption + integrity), AH (integrity only — no encryption). IKE Phase 1 (establish a secure channel to negotiate Phase 2 — ISAKMP SA). IKE Phase 2 (negotiate the actual IPSec SA for data traffic — ESP SA). The "lefty local, righty remotey" StrongSwan convention. Why NAT must be modified for VPN traffic — the POSTROUTING MASQUERADE rule would rewrite source IPs in the encrypted tunnel, breaking the routing.
- Lab 5A (80 min): Verify the existing S1/S3 topology. S3 already has an External NIC (on the classroom network) and a LAN2 NIC. Verify S3 can reach the internet. Confirm S1 and S3 can ping each other on their External IPs. Confirm S2 (on S1's LAN1) cannot reach S3's LAN2 address — this is the connectivity gap the VPN will fix. Configure S3 as a NAT gateway for its own internal subnet if not already done.
- Debrief (10 min): The key diagnostic check — can S1 ping S3's external IP? If not, the VPN cannot establish. This is the prerequisite for Tuesday's lab. Preview: StrongSwan uses the external IPs as tunnel endpoints; the internal subnets are what travel through the tunnel.
Instructor note: The topology verification on Monday is critical. Students who arrive at Tuesday's lab without confirmed S1↔S3 external connectivity will be unable to establish the IPSec tunnel regardless of configuration correctness. Spend the full lab time on topology verification — a working baseline on Monday saves hours of frustration on Tuesday.
Tuesday
Lab 5B · 2 hrs
StrongSwan PSK tunnel — ipsec.secrets, ipsec.conf, NAT exclusion, SA verification
0:00–0:10
Recap
0:10–1:50
Lab 5B
1:50–2:00
Debrief
- Recap (10 min): Verify S1 can ping S3's external IP and vice versa. If anyone doesn't have this — fix it now. Also check: S2 cannot ping S3's LAN IP. That's the gap. After today it should work.
- Lab 5B (100 min): Install strongswan on S1 and S3. Configure /etc/ipsec.secrets on both with the PSK. Write the ipsec.conf connection block on S1 (left=S1 external, leftsubnet=LAN1, right=S3 external, rightsubnet=S3's LAN). Mirror on S3. Modify the iptables NAT rule on both sides to exclude tunnel-bound traffic. Restart ipsec on both. Check ipsec status for the Security Association. Verify with a ping from S2 to S3's LAN IP — traffic goes through the encrypted tunnel. Confirm with tcpdump on S1's external interface showing ESP packets.
- Debrief (10 min): Ask: "What would happen if we didn't modify the NAT rule?" — packets from S2 bound for S3's LAN would be masqueraded before hitting the VPN, so their source IP would be S1's external IP rather than S2's internal IP. S3's routing would be confused and the return traffic would fail. The NAT exclusion is not optional. Preview Wednesday: upgrading from PSK to certificate-based auth.
Timing note: ipsec restart can take 15–30 seconds to negotiate the SA. Students who run ipsec status immediately after restart may see no SAs yet — advise them to wait 30 seconds before concluding there's a configuration error. The IKE negotiation takes time.
Wednesday
Lecture + Lab 5C · 2 hrs
PKI fundamentals, building a CA with strongswan-pki, issuing server certificates
0:00–0:10
Recap
0:10–0:40
Lecture
0:40–1:50
Lab 5C
1:50–2:00
Debrief
- Recap (10 min): PSK tunnel is working. Ask: "What's the security problem with a PSK?" — a shared secret that both sides know. If either side is compromised, the attacker knows the key. The key must be transmitted securely out-of-band. Managing PSKs at scale (hundreds of VPN tunnels) is an administrative nightmare. Certificates solve all of these problems.
- Lecture (30 min): PKI architecture — the trust chain. A root CA signs intermediate CAs (optional) which sign end-entity certificates. Anyone who trusts the root CA automatically trusts all certificates it has signed. In our case: a self-signed root CA on S3, which issues certificates for S1 and S3. S1 trusts caCert.pem → therefore trusts s3Cert.pem. S3 trusts caCert.pem → therefore trusts s1Cert.pem. The DN (Distinguished Name) fields — C (Country), O (Organisation), CN (Common Name). The SAN (Subject Alternative Name) — the hostname the cert is valid for. Certificate inspection with ipsec pki --print.
- Lab 5C (70 min): Install strongswan-pki on S3. Generate the CA private key (4096-bit RSA). Self-sign the root CA certificate (10-year validity). Inspect with ipsec pki --print. Generate S3's private key, extract the public key, issue S3's certificate signed by the CA. Repeat for S1. Copy the three necessary files to S1 (caCert.pem, s1Key.pem, s1Cert.pem). Verify file placement in /etc/ipsec.d/ directories.
Thursday
Lab 5D · 2 hrs
Migrate to certificate auth, verify SA, then build WireGuard and compare
0:00–0:10
Recap
0:10–1:50
Lab 5D
—
1:50–2:00
Wrap
- Recap (10 min): Verify certs are in place on both sides. Ask: "What three files does S1 need from S3?" — caCert.pem (to trust the CA), s1Key.pem (its own private key), s1Cert.pem (its own certificate). S3 keeps its own key/cert locally; it doesn't need to send those.
- Lab 5D Part 1 — Certificate migration (45 min): Update ipsec.secrets on both sides to RSA format. Update ipsec.conf on both sides: add keyexchange=ikev2, type=tunnel, leftcert, leftid, rightid. Restart ipsec. Verify SA with ipsec status — the certificate DN should now appear in the SA output. Confirm S2 can still ping S3's internal LAN IP through the now cert-authenticated tunnel.
- Lab 5D Part 2 — WireGuard (45 min): Install wireguard on S1 and S3. Generate key pairs on each. Create /etc/wireguard/wg0.conf on both sides with [Interface] and [Peer] sections. Bring up the interface: wg-quick up wg0. Verify with wg show. Test connectivity through the WireGuard tunnel. Compare: configuration file length, time to set up, tunnel status output, and performance considerations. WireGuard stays up for the assessment as a demonstration of both approaches running simultaneously — IPSec and WireGuard are not exclusive.
- Wrap (10 min): Direct comparison of IPSec and WireGuard. Preview Friday's assessment — practical is building a WireGuard tunnel from a specification. Students should be comfortable with the four-command WireGuard setup by now.
IPSec vs WireGuard on Thursday: The PSK tunnel from Tuesday and the cert-based tunnel should both be working before introducing WireGuard. WireGuard will use a different IP range (typically 10.0.0.x) for its virtual interface, separate from the IPSec tunnel. Having both running simultaneously is intentional — it shows they are independent technologies that can coexist.
Friday
Mini-Assessment 5 · 2 hrs
Written (30%) + Practical: bring up a WireGuard tunnel from a spec (70%)
0:00–0:30
Written
0:30–1:45
Practical
1:45–2:00
Review + Preview W7
- Written (30 min): IPSec IKE phases, PSK vs certificate auth pros/cons, ipsec.conf directive meanings, PKI trust chain, WireGuard key generation commands, [Interface]/[Peer] config syntax, IPSec vs WireGuard comparison.
- Practical (75 min): Students receive a WireGuard tunnel specification — IP addresses, peer public keys (pre-generated), and allowed IPs. They must configure both endpoints, bring up the tunnel, and demonstrate connectivity through it. The IPSec tunnel from the week's labs should still be running as a separate tunnel — they coexist.
- Review + Week 6 Preview (15 min): Walk through common WireGuard config mistakes. Preview Week 6: Docker containers, docker-compose, and the capstone — an Nginx reverse proxy in front of a Docker container, tying together Weeks 4 and 6.
Mini-Assessment 5 — Topic Coverage
| Topic | Weight | Source |
|---|
| IPSec architecture — IKE phases, ESP vs AH, tunnel vs transport | 15% | Monday lecture |
| PSK configuration — ipsec.secrets and ipsec.conf syntax | 15% | Lab 5B |
| NAT exclusion rule — why it's needed and how to write it | 10% | Lab 5B |
| PKI and certificate generation — CA, server certs, file distribution | 15% | Wednesday lecture + Lab 5C |
| Certificate-based ipsec.conf changes — leftcert, leftid, rightid | 10% | Lab 5D |
| WireGuard configuration — key gen, [Interface], [Peer] | 15% | Lab 5D |
| Practical: configure WireGuard tunnel from spec | 20% | All week |
What you need ready before Monday
All three VMs (S1, S2, S3) running with SSH accessible
S1 and S3 reachable on their External IPs from each other
Lab 5A, 5B, 5C, 5D handouts printed
Mini-Assessment 5 printed (Friday)
WireGuard practical spec prepared (pre-generate peer keys)
Confirm strongswan and wireguard packages available in apt